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Abstract 


We study sequential programs that are instruction sequences with 
direct and indirect jump instructions. The intuition is that indirect 
jump instructions are jump instructions where the position of the in- 
struction to jump to is the content of some memory cell. We consider 
several kinds of indirect jump instructions. For each kind, we define 
the meaning of programs with indirect jump instructions of that kind 
by means of a translation into programs without indirect jump instruc- 
tions. For each kind, the intended behaviour of a program with indirect 
jump instructions of that kind under execution is the behaviour of the 
translated program under execution on interaction with some memory 
device. 


1 Introduction 


We take the view that sequential programs are in essence sequences of in- 
structions. Although finite state programs with direct and indirect jump 
instructions are as expressive as finite state programs with direct jump in- 
structions only, indirect jump instructions are widely used. For example, 
return instructions, in common use to implement recursive method calls in 
programming language such as Java [11] and C# [12], are indirect jump 
instructions. Therefore, we consider a theoretical understanding of both 
direct jump instructions and indirect jump instructions highly relevant to 
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programming. In [3], sequential programs that are instruction sequences 
with direct jump instructions are studied. In this paper, we study sequential 
programs that are instruction sequences with both direct jump instructions 
and indirect jump instructions. 

We believe that interaction with components of an execution environ- 
ment, in particular memory devices, is inherent in the behaviour of programs 
under execution. Intuitively, indirect jump instructions are jump instruc- 
tions where the position of the instruction to jump to is the content of 
some memory cell. In this paper, we consider several kinds of indirect jump 
instructions, including return instructions. For each kind, we define the 
meaning of programs with indirect jump instructions of that kind by means 
of a translation into programs without indirect jump instructions. For each 
kind, the intended behaviour of a program with indirect jump instructions 
of that kind under execution is the behaviour of the translated program 
under execution on interaction with some memory device. We also describe 
the memory devices concerned, to wit register files and stacks. 

The approach to define the meaning of programs mentioned above is in- 
troduced under the name projection semantics in [3]. Projection semantics 
explains the meaning of programs in terms of known programs instead of 
more or less sophisticated mathematical objects that represent behaviours. 
The main advantage of projection semantics is that it does not require a 
lot of mathematical background. In the present case, another advantage 
of projection semantics is that it follows immediately that indirect jump 
instructions of the kinds considered can be eliminated from programs in 
the presence of an appropriate memory device. We will study sequential 
programs that are instruction sequences with direct and indirect jump in- 
structions in the setting in which projection semantics has been developed 
so far: the setting of program algebra and basic thread algebra.* 

Program algebra is an algebra of deterministic sequential programs 
based on the idea that such programs are in essence sequences of instruc- 
tions. Basic thread algebra is a form of process algebra which is tailored to 
the description of the behaviour of deterministic sequential programs under 
execution. A hierarchy of program notations rooted in program algebra is 
introduced in [3]. In this paper, we embroider on two program notations 
that belong to this hierarchy. The program notations in question, called 


3In [3], basic thread algebra is introduced under the name basic polarized process 
algebra. Prompted by the development of thread algebra [7], which is a design on top of 
it, basic polarized process algebra has been renamed to basic thread algebra. 
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PGLC and PGLD, are close to existing assembly languages. The main 
difference between them is that PGLC has relative jump instructions and 
PGLD has absolute jump instructions. 

A thread proceeds by doing steps in a sequential fashion. A thread 
may do certain steps only for the sake of having itself affected by some 
service. In [9], the use mechanism is introduced to allow for such interac- 
tion between threads and services. The interaction between behaviours of 
programs under execution and some memory device referred to above is an 
interaction of this kind. In this paper, we will use a slightly adapted form of 
the use mechanism, called thread-service composition, to have behaviours 
of programs under execution affected by services. 

This paper is organized as follows. First, we review basic thread alge- 
bra, program algebra, and the program notations PGLC and PGLD (Sec- 
tions 2, 3, and 4). Next, we extend basic thread algebra with thread-service 
composition and introduce a state-based approach to describe services (Sec- 
tions 5 and 6). Following this, we give a state-based description of register 
file services and introduce variants of the program notations PGLC and 
PGLD with indirect jump instructions (Sections 7, 8, and 9). We also in- 
troduce a variant of one of those program notations with double indirect 
jump instructions (Section 10). After that, we give a state-based description 
of stack services and introduce a variant of the program notation PGLD with 
returning jump instructions and return instructions (Sections 11 and 12). 
Finally, we make some concluding remarks (Section 13). 


2 Basic Thread Algebra 


In this section, we review BTA (Basic Thread Algebra), a form of process 
algebra which is tailored to the description of the behaviour of deterministic 
sequential programs under execution. The behaviours concerned are called 
threads. 

In BTA, it is assumed that there is a fixed but arbitrary finite set of 
basic actions A. The intuition is that each basic action performed by a 
thread is taken as a command to be processed by a service provided by the 
execution environment of the thread. The processing of a command may 
involve a change of state of the service concerned. At completion of the 
processing of the command, the service produces a reply value. This reply 
is either T or F and is returned to the thread concerned. 

Although BTA is one-sorted, we make this sort explicit. The reason 
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for this is that we will extend BTA with an additional sort in Section 5. 
The algebraic theory BTA has one sort: the sort T of threads. To build 
terms of sort T, BTA has the following constants and operators: 


e the deadlock constant D : T; 
e the termination constant S: T; 


e for each a € A, the binary postconditional composition operator 
_dab_:TxT-T. 


Terms of sort T are built as usual (see e.g. [16, 17]). Throughout the paper, 
we assume that there are infinitely many variables of sort T, including 
L,Y, 2. 

We use infix notation for postconditional composition. We introduce 
action prefizing as an abbreviation: ao p, where p is a term of sort T, 
abbreviates p Jab p. 

Let p and q be closed terms of sort T and a € A. Then pda q will 
perform action a, and after that proceed as p if the processing of a leads to 
the reply T (called a positive reply), and proceed as q if the processing of a 
leads to the reply F (called a negative reply). 

Each closed BTA term of sort T denotes a finite thread, i.e. a thread of 
which the length of the sequences of actions that it can perform is bounded. 
Guarded recursive specifications give rise to infinite threads. 

A guarded recursive specification over BTA is a set of recursion equa- 
tions FE = {X =tx | X € V}, where V is a set of variables of sort T and 
each tx is a term of the form D, S ort dal?’ with t and t’ BTA terms of 
sort T that contain only variables from V. We write V(£) for the set of all 
variables that occur on the left-hand side of an equation in &. We are only 
interested in models of BTA in which guarded recursive specifications have 
unique solutions, such as the projective limit model of BTA presented in [1]. 
A thread that is the solution of a finite guarded recursive specification over 
BTA is called a finite-state thread. 

We extend BTA with guarded recursion by adding constants for solu- 
tions of guarded recursive specifications and axioms concerning these ad- 
ditional constants. For each guarded recursive specification E and each 
X € V(E), we add a constant of sort T standing for the unique solution 
of EF for X to the constants of BTA. The constant standing for the unique 
solution of F for X is denoted by (X|E). Moreover, we add the axioms for 
guarded recursion given in Table 1 to BTA, where we write (tx|E) for tx 
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Table 1: Axioms for guarded recursion 
(X|F) = (tx|E) if X=tx € E RDP 
E> X=(X|E) if X €V(E) RSP 


with, for all Y € V(£), all occurrences of Y in tx replaced by (Y|E). In this 
table, X, tx and EF stand for an arbitrary variable of sort T, an arbitrary 
BTA term of sort T and an arbitrary guarded recursive specification over 
BTA, respectively. Side conditions are added to restrict the variables, terms 
and guarded recursive specifications for which X, ty and FE stand. The 
equations (X|F) = (tx|E) for a fixed E express that the constants (X|F) 
make up a solution of E. The conditional equations E > X = (X|EF) 
express that this solution is the only one. 

We will write BTA+REC for BTA extended with the constants for 
solutions of guarded recursive specifications and axioms RDP and RSP. 

In [5], we show that the threads considered in BTA+REC can be viewed 
as processes that are definable over ACP [10]. 


3 Program Algebra 


In this section, we review PGA (ProGram Algebra), an algebra of sequen- 
tial programs based on the idea that sequential programs are in essence 
sequences of instructions. PGA provides a program notation for finite-state 
threads. 

In PGA, it is assumed that there is a fixed but arbitrary finite set 2 of 
basic instructions. PGA has the following primitive instructions: 


e for each a € 2, a plain basic instruction a; 

e for each a € A, a positive test instruction +a; 
e for each a € A, a negative test instruction —a; 
e for each 1 CN, a forward jump instruction #1: 
e a termination instruction !. 


We write 3 for the set of all primitive instructions. 
The intuition is that the execution of a basic instruction a may modify 
a state and produces T or F at its completion. In the case of a positive 
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test instruction +a, basic instruction a is executed and execution proceeds 
with the next primitive instruction if T is produced and otherwise the next 
primitive instruction is skipped and execution proceeds with the primitive 
instruction following the skipped one. In the case where T is produced and 
there is not at least one subsequent primitive instruction and in the case 
where F is produced and there are not at least two subsequent primitive 
instructions, deadlock occurs. In the case of a negative test instruction 
—a, the role of the value produced is reversed. In the case of a plain basic 
instruction a, the value produced is disregarded: execution always proceeds 
as if T is produced. The effect of a forward jump instruction #1 is that 
execution proceeds with the /-th next instruction of the program concerned. 
If J equals 0 or the /-th next instruction does not exist, then #/ results 
in deadlock. The effect of the termination instruction ! is that execution 
terminates. 
PGA has the following constants and operators: 


e for each u € 3, an instruction constant wu; 
e the binary concatenation operator _;_; 


e the unary repetition operator _“. 


Terms are built as usual. Throughout the paper, we assume that there are 
infinitely many variables, including z, y, z. 

We use infix notation for concatenation and postfix notation for repe- 
tition. 

Closed PGA terms are considered to denote programs. The intuition 
is that a program is in essence a non-empty, finite or infinite sequence of 
primitive instructions. These sequences are called single pass instruction 
sequences because PGA has been designed to enable single pass execution 
of instruction sequences: each instruction can be dropped after it has been 
executed. Programs are considered to be equal if they represent the same 
single pass instruction sequence. The axioms for instruction sequence equiv- 
alence are given in Table 2. In this table, n stands for an arbitrary natural 
number greater than 0. For each n > 0, the term x” is defined by induc- 
tion on n as follows: 2! = 2 and 2"t! = x; 2". The unfolding equation 
xz” = 2;2” is derivable. Each closed PGA term is derivably equal to a term 
in canonical form, i.e. a term of the form P or P; Q”, where P and Q are 
closed PGA terms that do not contain the repetition operator. 

Each closed PGA term is considered to denote a program of which the 
behaviour is a finite-state thread, taking the set 2 of basic instructions for 
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Table 2: Axioms of PGA 
ese =a eye) “PGAL 


Cae ea PGA2 
fa fe! Fa PGA3 
z;y)’=2;(y;2)” PGA4 


Table 3: Defining equations for thread extraction operator 


a|=aoD #1| =D 
a+ 2| = a@o-le| #050) 2=D 
+al =a0D #1; 0| = [| 
t+a;2|=|z| dab |#2;2|  |#l+2;u]=D 
—a|=aoD #14+2;u;2| = |#l+1;52| 
—a;2|=|#2;2|dab|z| |!/=S 

!;a/=S 


Table 4: Rule for cyclic jump chains 


mY 4 


pay = |e =D 


the set A of actions. The thread extraction operator |_| assigns a thread to 
each program. The thread extraction operator is defined by the equations 
given in Table 3 (for a € &, 1 € N and u € J) and the rule given in Table 4. 
This rule is expressed in terms of the structural congruence predicate _ = _, 
which is defined by the formulas given in Table 5 (for n,m,l € N and 
U1, +++5Un, U1,++-5Um41 3). 

The equations given in Table 3 do not cover the case where there is a 
cyclic chain of forward jumps. Programs are structural congruent if they 
are the same after removing all chains of forward jumps in favour of single 
jumps. Because a cyclic chain of forward jumps corresponds to #0, the rule 
from Table 4 can be read as follows: if x starts with a cyclic chain of forward 
jumps, then || equals D. It is easy to see that the thread extraction operator 
assigns the same thread to structurally congruent programs. Therefore, the 
rule from Table 4 can be replaced by the following generalization: « = y > 
|z| = lyl- 


25 


Table 5: Defining formulas for structural congruence predicate 
fn +13u13...5Un3 #0 = #0; u1;...5 Un; #0 


#n+13;uzr;...;Un;#m=#m4+n4+13u13...5Unj3; F#m 
(n+l +1; ur;...;Un)® = (Hl; ur 3... 5 Un)* 
fem. al 23 yg 3 es ti} On i Opa)? = 

Fen be ais oo ty S01 8 Dy)” 
u=ux 


i, = Up Ne Se Se ee ss ea SH 


Let E be a finite guarded recursive specification over BTA, and let Py 
be aclosed PGA term for each X € V(E). Let E’ be the set of equations that 
results from replacing in E all occurrences of X by |Px| for each X € V(E). 
If E’ can be obtained by applications of axioms PGA1—PGA4, the defining 
equations for the thread extraction operator and the rule for cyclic jump 
chains, then |Px| is the solution of E for X. Such a finite guarded recursive 
specification can always be found. Thus, the behaviour of each closed PGA 
term, is a thread that is definable by a finite guarded recursive specification 
over BTA. Moreover, each finite guarded recursive specification over BTA 
can be translated to a closed PGA term of which the behaviour is the 
solution of the finite guarded recursive specification concerned. 

Closed PGA terms are loosely called PGA programs. PGA programs in 
which the repetition operator do not occur are called finite PGA programs. 


4 ‘The Program Notations PGLC and PGLD 


In this section, we review two program notations which are rooted in PGA. 
These program notations, called PGLC and PGLD, belong to a hierarchy 
of program notations introduced in [3]. 

Both PGLC and PGLD are close to existing assembly languages. The 
main difference between them is that PGLC has relative jump instructions 
and PGLD has absolute jump instructions. PGLC and PGLD have no 
explicit termination instruction. 

In PGLC and PGLD, like in PGA, it is assumed that there is a fixed 
but arbitrary finite set of basic instructions 2. Again, the intuition is that 
the execution of a basic instruction a may modify a state and produces T 
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or F at its completion. 
PGLC has the following primitive instructions: 


e for each a € 2, a plain basic instruction a; 

e for each a € A, a positive test instruction +a; 

e for each a € A, a negative test instruction —a; 

e for each 1 CN, a direct forward jump instruction #1, 

e for each 1 € N, a direct backward jump instruction \#l. 


PGLC programs have the form u1;...; ug, where u,,..., uz are primitive 
instructions of PGLC. 

The plain basic instructions, the positive test instructions, and the 
negative test instructions are as in PGA, except that termination instead of 
deadlock occurs in the case where there are insufficient subsequent primitive 
instructions. The effect of a direct forward jump instruction #/ is that 
execution proceeds with the /-th next instruction of the program concerned. 
If J equals 0, then deadlock occurs. If the /-th next instruction does not exist, 
then termination occurs. The effect of a direct backward jump instruction 
\#l is that execution proceeds with the /-th previous instruction of the 
program concerned. If / equals 0, then deadlock occurs. If the /-th previous 
instruction does not exist, then termination occurs. 

We define the meaning of PGLC programs by means of a function 
pglc2pga from the set of all PGLC programs to the set of all PGA programs. 
This function is defined by 


pelc2pga(uy;...; ue) = (Wi(ur);...3 velar) 3 !5 9%, 


where the auxiliary functions ~; from the set of all primitive instructions of 
PGLC to the set of all primitive instructions of PGA are defined as follows 
(I< 97<k): 


(#1) = #l ifgjti<ck, 

wj(#l) =! Le wt eee 

w;(\#l) = #k+2-Lifl <j, 

dil\#) =! f1>j, 

wj(u) =u if wis not a jump instruction . 
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The idea is that each backward jump can be replaced by a forward jump 
if the entire program is repeated. To enforce termination of the program 
after execution of its last instruction if the last instruction is a plain basic 
instruction, a positive test instruction or a negative test instruction, !;! is 
appended to 71 (u1) ;.--5 Ve(ue). 

Let P be a PGLC program. Then pglc2pga(P) represents the mean- 
ing of P as a PGA program. The intended behaviour of P is the be- 
haviour of pglc2pga(P). That is, the behaviour of P, written |Plparc, 
is |pglc2pga(P)]. 

PGLD has the following primitive instructions: 


e for each a € 2, a plain basic instruction a; 

e for each a € 2, a positive test instruction +a; 

e for each a € A, a negative test instruction —a; 

e for each 1 EN, a direct absolute jump instruction ##1. 


PGLD programs have the form u4;...; uz, where uj1,..., uz are primitive 
instructions of PGLD. 

The plain basic instructions, the positive test instructions, and the 
negative test instructions are as in PGLC. The effect of a direct absolute 
jump instruction ##I is that execution proceeds with the /-th instruction of 
the program concerned. If ##1 is itself the [-th instruction, then deadlock 
occurs. If / equals 0 or / is greater than the length of the program, then 
termination occurs. 

We define the meaning of PGLD programs by means of a function 
pgld2pgic from the set of all PGLD programs to the set of all PGLC 
programs. This function is defined by 


pgld2pglc(uy ;...; ue) = Yilur);...; Value) , 


where the auxiliary functions ~; from the set of all primitive instructions 
of PGLD to the set of all primitive instructions of PGLC are defined as 
follows (1 <j <k): 


O(FED Hig ifla9; 
wj (FHL) = \#I —Lifl <j, 


wj(u) =u if w is not a jump instruction . 
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Let P be a PGLD program. Then pgld2pgic(P) represents the mean- 
ing of P as a PGLC program. The intended behaviour of P is the be- 
haviour of pgld2pglc(P). That is, the behaviour of P, written |P|pazp, is 
|pgld2pglc(P)|patc. 

We use the phrase projection semantics to refer to the approach to 
semantics followed in this section. The meaning functions pglc2pga and 
pgld2pglc are called projections. 

PGLC and PGLD are very simple program notations. The hierarchy 
of program notations introduced in [3] also includes a program notation, 
called PGLS, that supports structured programming by offering conditional 
and loop constructs instead of (unstructured) jumps. Each PGLS program 
can be translated into a semantically equivalent PGLD program by means 
of a number of projections. 


5 Interaction of Threads with Services 


A thread may perform certain actions only for the sake of getting reply 
values returned by a service and that way having itself affected by that 
service. In this section, we introduce thread-service composition, which 
allows for threads to be affected by services in this way. We will only use 
thread-service composition to have program behaviours affected by a service. 
Thread-service composition is a slightly adapted form of the use mechanism 
introduced in [9]. 

We consider only deterministic services. This will do in the case that 
we address: services that keep private data for a program. The services 
concerned are para-target services by the classification given in [6]. 

It is assumed that there is a fixed but arbitrary finite set of foci F and 
a fixed but arbitrary finite set of methods M. Each focus plays the role 
of a name of a service provided by the execution environment that can be 
requested to process a command. Each method plays the role of a command 
proper. For the set A of actions, we take the set {f.m | f € F,m € M}. 
Performing an action f.m is taken as making a request to the service named 
f to process command m. 

We introduce yet another sort: the sort S of services. However, we 
will not introduce constants and operators to build terms of this sort. S 
is a parameter of theories with thread-service composition. S is considered 
to stand for the set of all services. It is assumed that each service can 
be represented by a function H : M+ — {T,F,B} with the property that 
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Table 6: Axioms for thread-service composition 


S/pH=S TSC1 
D/;H=D TSC2 
(cdgmby) /pH =(a/pH)dgmb(y/;H) if fA TSC3 
(cxifmby)/;H=2/; 2H if H((m))=T TSC4 
(xif.mby) /pH=y/p oH if H((m)) =F TSC5 
(cdfmb y)/pH=D if H((m)) =B TSC6 


H(a) =B => H(a~(m)) =B for alla € M* and m € M. This function 
is called the reply function of the service. Given a reply function H and a 
method m € M, the derived reply function of H after processing m, written 
x H, is defined by 2 H(a) = H((m) ~a). 

The connection between a reply function H and the service represented 
by it can be understood as follows: 


e if H((m)) =T, the request to process command m is accepted by the 
service, the reply is positive and the service proceeds as oH : 


e if H((m)) =F, the request to process command m is accepted by the 
service, the reply is negative and the service proceeds as 3H : 


e if H((m)) =B, the request to process command m is not accepted by 
the service. 


Henceforth, we will identify a reply function with the service represented by 
it. 

For each f € F, we introduce the binary thread-service composition 
operator _ /p _:T x S — T. Intuitively, p /s H is the thread that results 
from processing all actions performed by thread p that are of the form f.m 
by service H. Service H affects thread p by means of the reply values 
produced at completion of the processing of the actions performed by p. 
The actions processed by H are no longer observable. 

The axioms for the thread-service composition operator are given in 
Table 6. In this table, f stands for an arbitrary focus from F, m stands for 
an arbitrary method from M. Axiom TSC3 expresses that actions of the 
form g.m, where f # g, are not processed. Axioms TSC4 and TSC5 express 
that a thread is affected by a service as described above when an action of 
the form f.m performed by the thread is processed by the service. Axiom 
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TSC6 expresses that deadlock takes place when an action to be processed 
is not accepted. 

Let T stand for either BTA or BTA+REC. Then we will write T+TSC 
for T, taking the set {f.m | f € F,m € M} for A, extended with the 
thread-service composition operators and the axioms from Table 6. 

In [5], we show that the services considered here can be viewed as 
processes that are definable over an extension of ACP with conditionals 
introduced in [4]. 


6 State-Based Description of Services 


In this section, we introduce the state-based approach to describe families of 
services that will be used later on. This approach is similar to the approach 
to describe state machines introduced in [9]. 

In this approach, a family of services is described by 


e aset of states S; 
e an effect function eff :M x S — S; 
e a yield function yld: M x S — {T,F,B}; 


satisfying the following condition: 


dseSeVnmEe Me 
(yld(m,s) =BAVs' € Se (yld(m, s') =B => eff(m,s’) =s)). 


The set S' contains the states in which the services may be; and the func- 
tions eff and yld give, for each method m and state s, the state and reply, 
respectively, that result from processing m in state s. 

We define, for each s € S, a cumulative effect function ceff,: M* — S 
in terms of s and eff as follows: 


( 
ceff .(a 0% (m)) = eff (m, ceff ,(@)) ; 


We define, for each s € S, a service H,: Mt — {T,F,B} in terms of ceff , 
and yld as follows: 


Hs(a~ (m)) = yld(m, ceff .(@)) . 
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H, is called the service with initial state s described by S, eff and yld. We 
say that {H, | s € S} is the family of services described by S, eff and yld. 

For each s € S, H, is a service indeed: the condition imposed on S, 
eff and yld implies that H,(a) = B => H,(a~(m)) =B for all ae Mt 
and m € M. It is worth mentioning that H,((m)) = yld(m,s) and aH = 
AL eff (m,s): 


7 Register File Services 


In this section, we give a state-based description of the very simple family 
of services that constitute a register file of which the registers can contain 
natural numbers up to some bound. This register file will be used in Sec- 
tions 8-10 to describe the behaviour of programs in variants of PGLC and 
PGLD with indirect jump instructions. 

It is assumed that a fixed but arbitrary number J has been given, 
which is considered the number of registers available. It is also assumed 
that a fixed but arbitrary number N has been given, which is considered 
the greatest natural number that can be contained in a register. 

The register file services accept the following methods: 


e for each i € [0,7] and n € [0, N], a register set method set:i:n; 
e for each 7 € [0,7] and n € [0, N], a register test method eq:i:n. 


We write Mregs for the set {set:i:n,eq:i:n | i € [0,J] An € [0,N]}. It is 
assumed that Mregs C M. 

The methods accepted by register file services can be explained as fol- 
lows: 


e set:i:n: the contents of register 1 becomes n and the reply is T; 


e eq:i:n: if the contents of register 7 equals n, then nothing changes and 
the reply is T; otherwise nothing changes and the reply is F. 


Let s:[{1,Z] — [0, N]. Then we write Regs, for the service with initial 
state s described by S = ([1, 1] — [0, N])U{T}, where 7 ¢ [1, I] — [0, N], and 
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the functions eff and yld defined as follows (n € [0, N], p: [1,Z] — [0, N]):* 


ff (set:i:n, p) =p@lirnn], 
eq:i:n, p) =p, 
on ifm Z Meegs ; 


elf ( 
elf ( 
elf ( 
elf (m, 1) = 
yld(set:i:n, p) =T, 
( 
( 
(m 
(m 


yld(eq:i:n, p) = T if p(i) =n 
yld(eq:i:n, oe F if p(t) An, 
yld or) = if m ¢ Meegs ’ 


yld(m,T) = 


We write Regsini, for Regsi1.o}6...e[140]: 


8 PGLD with Indirect Jumps 


In this section, we introduce a variant of PGLD with indirect jump instruc- 
tions. This variant is called PGLDj;. 

In PGLD;j;, it is assumed that there is a fixed but arbitrary finite set 
of foci F with regs € F and a fixed but arbitrary finite set of methods M. 
Moreover, we adopt the assumptions made about register file services in 
Section 7. The set {f.m | f € F,m € M} is taken as the set 2 of basic 
instructions. 

PGLD;; has the following primitive instructions: 


e for each a € 2, a plain basic instruction a; 

e for each a € YA, a positive test instruction +a; 

e for each a € A, a negative test instruction —a; 

e for each 1 EN, a direct absolute jump instruction ##1:; 

e for each 7 € [1, I], an indirect absolute jump instruction i##1. 


PGLDj; programs have the form u;;...; uz, where uj,..., ug are primitive 
instructions of PGLD). 


4We use the following notation for functions: f ® g for the function h with dom(h) = 
dom(f) Udom(g) such that for all d € dom(h), h(d) = f(d) if d € dom(g) and h(d) = g(d) 
otherwise; and [d+> r] for the function f with dom(f) = {d} such that f(d) = 
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The plain basic instructions, the positive test instructions, the negative 
test instructions, and the direct absolute jump instructions are as in PGLD. 
The effect of an indirect absolute jump instruction i##i is that execution 
proceeds with the /-th instruction of the program concerned, where | is the 
content of register i. If i##7 is itself the /-th instruction, then deadlock oc- 
curs. If l equals 0 or / is greater than the length of the program, termination 
occurs. 

Recall that the content of register 7 can be set to | by means of the 
basic instruction regs.set:2:1. Initially, its content is 0. 

Like before, we define the meaning of PGLD,; programs by means of a 
function pgldij2pgld from the set of all PGLDj; programs to the set of all 
PGLD programs. This function is defined by 


pgldij2pgld(wi ;...; ux) = 
W(t) 3 ~..3 lug) 5 HO 5 AHO; 
+regs.eq:1:1 ; ##1;...; +regs.eq:l:n ; #4n ; ##0; 
+regs.eq:I:1; #441;...; +regs.eq:I:n ; #4n ; #40 , 


where n = min(k, N) and the auxiliary function w from the set of all primi- 
tive instructions of PGLDj; to the set of all primitive instructions of PGLD 
is defined as follows: 


vl =##L ifl<k, 
v##) =##0 ifl>k, 
ith) = ##L , 
( 


u) =u if wis not a jump instruction , 
and for each 7 € [1, I]: 
L=k+3+(2-min(k,N)+1)-(@-1). 


The idea is that each indirect absolute jump can be replaced by a direct 
absolute jump to the beginning of the instruction sequence 


+regs.eq:i:1 ; #741;...; +regs.eq:i:n ; #41 ; 40 , 


where 7 is the register concerned and n = min(k, N). The execution of this 
instruction sequence leads to the intended jump after the content of the 
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register concerned has been found by a linear search. To enforce termination 
of the program after execution of its last instruction if the last instruction 
is a plain basic instruction, a positive test instruction or a negative test 
instruction, ##0 ; ##0 is appended to W(u1);...; W(ug). Because the 
length of the translated program is greater than k, care is taken that there 
are no direct absolute jumps to instructions with a position greater than k. 
Obviously, the linear search for the content of a register can be replaced by 
a binary search. 

Let P be a PGLD;; program. Then pgldij2pgld(P) represents the 
meaning of P as a PGLD program. The intended behaviour of P is the 
behaviour of pgldij2pgld(P) on interaction with a register file. That is, 
the behaviour of P, written |P|paxn,,, is |pgldij2pgld(P)|parp /regs Regsinit- 

More than one instruction is needed in PGLD to obtain the effect of 
a single indirect absolute jump instruction. The projection pgldij2pgld 
deals with that in such a way that there is no need for the unit instruction 
operator introduced in [15] or the distinction between first-level instructions 
and second-level instructions introduced in [2]. 


9 PGLC with Indirect Jumps 


In this section, we introduce a variant of PGLC with indirect jump instruc- 
tions. This variant is called PGLC;. 

In PGLC;;, the same assumptions are made as in PGLDj;. Like in 
PGLDjj, the set {f.m | f € F,m € M} is taken as the set 2 of basic 
instructions. 

PGLDj; has the following primitive instructions: 


e for each a € 2, a plain basic instruction a; 
e for each a € A, a positive test instruction +a; 
e for each a € A, a negative test instruction —a; 


for each 1 € N, a direct forward jump instruction #1: 


for each | € N, a direct backward jump instruction \#1; 


e for each i € [1, I], an indirect forward jump instruction i#i; 


e for each i € [1, I], an indirect backward jump instruction i\#1. 
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PGLC;; programs have the form uj ;...; uz, where uj,..., ug are primitive 
instructions of PGLCj. 

The plain basic instructions, the positive test instructions, the nega- 
tive test instructions, the direct forward jump instructions, and the direct 
backward jump instructions are as in PGLC. The effect of an indirect for- 
ward jump instruction i#i is that execution proceeds with the /-th next 
instruction of the program concerned, where / is the content of register 7. If 
1 equals 0, then deadlock occurs. If the [-th next instruction does not exist, 
then termination occurs. The effect of an indirect backward jump instruc- 
tion i\#z is that execution proceeds with the /-th previous instruction of 
the program concerned, where / is the content of register i. If 1 equals 0, 
then deadlock occurs. If the /-th previous instruction does not exist, then 
termination occurs. 

We define the meaning of PGLC;; programs by means of a function 
pglcij2pglc from the set of all PGLC;; programs to the set of all PGLC 
programs. This function is defined by 


pelcij2pele(ais-..7u,) = 
Wi(ur);---3We(ue); \#R+1;\#k +2; 
+regs.eq:1:0 ; \#l,193---3 +regs.eq:1:N ; \#U, 1 3 


+-regs.eq:1:0 ; \#l, 4.0 >...3 bregs.eq:1:N ; \#U bw ; 


+regs.eq:l:0 ; \#l7 1 95--.3 tregs.eqsl:N ;\#l7 1 n 


+regs.eq:1:0 ; \#17 9 3--+5 tregs.eq:I:N 5 \#07 yw 5 
+regs.eq:1:0 ; \#1, 19 3---3 tregs.eq:l:N ; \#0 1 3 


+regs.eq:1:0 ; \#0 0 >...3 +regs.eq:1:N ; \#l nn : 


+regs.eq:I:0 ; \#lr 1.0 >...3 tregs.eq:I:N ; \#lr ; 


+regs.eq:I:0; \#l7 4.0 >...3 tregs.eq:I:N ; \#lr bw : 
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where the auxiliary functions ~; from the set of all primitive instructions of 
PGLG;; to the set of all primitive instructions of PGLC is defined as follows 
(l<j<hk): 


#1) =#l  ifg+i<k, 
iH) =\#i ifi+tl>k, 


u) =u if wis not a jump instruction , 


and for each 7 € [1, J], j € [1,k], and h € [0, N]: 


lg =k+3+2-(N+1)-(k-G@—-1)+G-)), 

Lg =R+3+2-(N+1)-(k-U+i-)+G-)), 

lign Hag +2-h+1—(G+h) if j+th<k, 
Ugh = RT8+2-(N4+1) KT if jth>k, 
gn = lgt+2-h+1—-G-h) ifj-h>0, 
Up =k+344-(N41)-k-1 fp See. 


Like in the case of indirect absolute jumps, the idea is that each indirect 
forward jump and each indirect backward jump can be replaced by a direct 
forward jump to the beginning of an instruction sequence whose execution 
leads to the intended jump after the content of the register concerned has 
been found by a linear search. However, the direct backward jump instruc- 
tions occurring in that instruction sequence now depend upon the position 
of the indirect jump concerned in u,;...; ug. To enforce termination of 
the program after execution of its last instruction if the last instruction is a 
plain basic instruction, a positive test instruction or a negative test instruc- 
tion, \#k +1; \#k +2 is appended to ¥1(w1);...; Ue(uzg). Because the 
length of the translated program is greater than k, care is taken that there 
are no direct forward jumps to instructions with a position greater than k. 

Let P be a PGLC, program. Then pglcij2pglc(P) represents the 
meaning of P as a PGLC program. The intended behaviour of P is the 
behaviour of pglcij2pglc(P) on interaction with a register file. That is, 
the behaviour of P, written |P|paro,, is |pgleij2pglc(P)|parc /regs Regsinit- 

The projection pglcij2pglic yields needlessly long PGLC programs 
because it does not take into account the fact that there is at most one 
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indirect jump instruction at each position in a PGLC;; program being pro- 
jected. Taking this fact into account would lead to a projection with a much 
more complicated definition. 


10 PGLD with Double Indirect Jumps 


In this section, we introduce a variant of PGLDj; with double indirect jump 
instructions. This variant is called PGLDajj. 

In PGLDgij, the same assumptions are made as in PGLDj. Like in 
PGLDjj, the set {f.m | f € F,m € M} is taken as the set 2 of basic 
instructions. 

PGLDgij has the following primitive instructions: 


e for each a € 2, a plain basic instruction a; 
e for each a € A, a positive test instruction +a; 
e for each a € A, a negative test instruction —a; 


for each 1 € N, a direct absolute jump instruction ##1:; 


e for each 7 € [1, I], an indirect absolute jump instruction i#¢#1; 
e for each i € [1, I], a double indirect absolute jump instruction ii#-#i. 


PGLDgj; programs have the form u,;...;uz, where uy,..., uz are primitive 
instructions of PGLDgjj. 

The plain basic instructions, the positive test instructions, the negative 
test instructions, the direct absolute jump instructions, and the indirect 
absolute jump instruction are as in PGLDj;. The effect of a double indirect 
absolute jump instruction ii##7 is that execution proceeds with the /-th 
instruction of the program concerned, where / is the content of register 7’, 
where 7’ is the content of register 7. If ii##7 is itself the J-th instruction, 
then deadlock occurs. If / equals 0 or / is greater than the length of the 
program, termination occurs. 

Like before, we define the meaning of PGLDg;j programs by means of 
a function pglddij2pgldij from the set of all PGLD4gjj programs to the set 
of all PGLD;; programs. This function is defined by 
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pglddij2pgldij(uy;...; up) = max(k+2,N)—(k+2) 
rN 
(ur) 3... 3 W(ux) 5 FAO ; HO 5 HO; ... 5 #0; 
+regs.eq:1:1 ; ift##1;...; +regs.eq:1:n ; ift#tn ; ##0; 


+regs.eq:I:1 ; i##1;...; +regs.eq:I:n ; i#4#n ; #H0 , 


where n = min(J, NV) and the auxiliary function w from the set of all primi- 
tive instructions of PGLDgjj to the set of all primitive instructions of PGLD); 
is defined as follows: 


v##) =##L ifl<k, 


U(##l) =##0 if >k, 

WitHt) = iH , 

U(iigtHt) = HL , 

w(u) 4) if wis not a jump instruction , 


and for each i € [1, I]: 
i =N+14+(2-minU,N)+1)-(@-1). 


The idea is that each double indirect absolute jump can be replaced by an 
indirect absolute jump to the beginning of the instruction sequence 


+regs.eq:i:1 ; i##7#1;...; +regs.eq:i:n ; i#Ftn ; #H40 , 


where 7 is the register concerned and n = min(I, NV). The execution of this 
instruction sequence leads to the intended jump after the content of the 
register concerned has been found by a linear search. To enforce termination 
of the program after execution of its last instruction if the last instruction 
is a plain basic instruction, a positive test instruction or a negative test 
instruction, ##0;##0 is appended to w(u1);...;2(uz). Because the length 
of the translated program is greater than k, care is taken that there are no 
direct absolute jumps to instructions with a position greater than k. To deal 
properly with indirect absolute jumps to instructions with a position greater 
than k, the instruction ##0 is appended to w(u1);...; (ux) ; ##0 ; #40 
a sufficient number of times. 

Let P be a PGLDaij program. Then pglddij2pgldij(P) represents the 
meaning of P as a PGLD;; program. The intended behaviour of program 
P is the behaviour of pglddij2pgldij(P). That is, the behaviour of P, 
written |P|parp,,, 18 [pglddij2pgldij(P)|prcry,;- 
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The projection pglddij2pgldij uses indirect absolute jumps to ob- 
tain the effect of a double indirect absolute jump in the same way as the 
projection pgldij2pgld uses direct absolute jumps to obtain the effect of 
an indirect absolute jump. Likewise, indirect relative jumps can be used in 
that way to obtain the effect of a double indirect relative jump. Moreover, 
double indirect jumps can be used in that way to obtain the effect of a triple 
indirect jump, and so on. 


11 Stack Services 


In this section, we give a state-based description of the very simple family 
of services that constitute a bounded stack of which the elements are nat- 
ural numbers up to some bound. This stack will be used in Section 12 to 
describe the behaviour of programs in a variant of PGLD with returning 
jump instructions and return instructions. 

It is assumed that a fixed but arbitrary number J has been given, which 
is considered the greatest length of the stack. It is also assumed that a fixed 
but arbitrary number N has been given, which is considered the greatest 
natural number that can be an element of the stack. 

The stack services accept the following methods: 


e for each n € [0, N], a stack push method push:n; 
e for each n € [0, N], a stack top test method topeq:n; 


e a stack pop method pop. 


We write Metack for the set {push:n, topeq:n | n € [0, N]}U {pop}. It is 
assumed that Metack GC M. 
The methods of stack services can be explained as follows: 


e push:n: if the length of the stack is less than J, then the number n is 
put on top of the stack and the reply is T; otherwise nothing changes 
and the reply is F; 


e topeq:n: if the stack is not empty and the number on top of the 
stack is n, then nothing changes and the reply is T; otherwise nothing 
changes and the reply is F; 


e pop: if the stack is not empty, then the number on top of the stack is 
removed from the stack and the reply is T; otherwise nothing changes 
and the reply is F. 
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Let s € [0, N]” be such that len(s) < J. Then we write Stack, for the 
service with initial state s described by S = {o € [0, N]* | len(c) < J}U{f}, 
where | ¢ {o € [0, N]* | len(o) < J}, and the functions eff and yld defined 
as follows (n,n! € [0, NJ, o € [0, N]*):° 


eff (push:n,a) = (n)~o_ if len(o) < J, 


eff (push:n,a) =o if len(o) > J, 
eff (topeq:n,a) =o, 

eff (pop, (n) ~o) =a, 

eff (pop, ()) = (), 

eff(m,a) =T ifm € Mstack 
eff(m, 1) =T, 

yld(push:n, 0) = T if len(o) < J, 
yld(push:n, 0) = F if len(o) > J, 
yld(topeq:n, (n’) +0) =Tifn=n’', 
yld(topeq:n, (n') ~c) =F ifn#n’, 
yld(topeq:n, ()) =F, 

yld(pop, (n) ~o) =T, 

yld(pop, ()) =F, 

yld(m,o) =B ifm € Metack 5 
yld(m,t) =B 


We write Stackini for Stack ). 


12 PGLD with Returning Jumps and Returns 


In this section, we introduce a variant of PGLD with returning jump in- 
structions and return instructions. This variant is called PGLD,;. 

In PGLD,;, like in PGLDjj, it is assumed that there is a fixed but 
arbitrary finite set of foci F with stack € F and a fixed but arbitrary finite 
set of methods M. Moreover, we adopt the assumptions made about stack 
services in Section 11. The set {f.m | f € F \ {stack},m € M} is taken as 
the set 2l of basic instructions. 


>We write D* for the set of all finite sequences with elements from set D. We use the 
following notation for finite sequences: () for the empty sequence, (d) for the sequence 
having d as sole element, o ~ o’ for the concatenation of finite sequences o and o’, and 
len(c) for the length of finite sequence o. 
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PGLD,,; has the following primitive instructions: 
e for each a € 2, a plain basic instruction a; 
e for each a € YA, a positive test instruction +a; 


e for each a € A, a negative test instruction —a; 


for each 1 € N, an absolute jump instruction ##1; 
e for each 1 EN, a returning absolute jump instruction r##1: 
e an absolute return instruction ##r. 


PGLD,; programs have the form uj ;...; uz, where u1,..., ug are primitive 
instructions of PGLD,;. 

The plain basic instructions, the positive test instructions, the nega- 
tive test instructions, and the absolute jump instructions are as in PGLD. 
The effect of a returning absolute jump instruction r##l is that execution 
proceeds with the /-th instruction of the program concerned, but execution 
returns to the next primitive instruction on encountering a return instruc- 
tion. If r##1 is itself the /-th instruction, then deadlock occurs. If | equals 
0 or | is greater than the length of the program, termination occurs. The 
effect of a return instruction ##r is that execution proceeds with the in- 
struction immediately following the last executed returning absolute jump 
instruction to which a return has not yet taken place. 

Like before, we define the meaning of PGLD,; programs by means of a 
function pgldrj2pgld from the set of all PGLD,; programs to the set of all 
PGLD programs. This function is defined by 


pgldrj2pgld(uy;...5; ux) = 
Pi(ur) 3 ---3 Value) 5 AO 5 HO 5 
+stack.push:1 ; #41; ##I1";...; +stack.push:1; ##k;##1" ; 


+stack.push:n ; ##1;##1”" ;...;+stack.push:n; ##k;##1" ; 
—stack.topeq:1 ; ##1// ; stack.pop ; ##1; 


—stack.topeq:n ; ##1” ; stack.pop ; ###n ; 
Hl" , 
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where n = min(k, N) and the auxiliary functions ~; from the set of all 
primitive instructions of PGLD,; to the set of all primitive instructions of 
PGLD is defined as follows (1 < j < k): 


vit) =##L if <k, 

yi (##l) =##0 ifT>k, 

(HHL) = HBL 

Dir) = HH, 

bj( 

and for each j € [1,k], 1 € N, and h € [1, min(k, N)]: 


u) =u if wis not a jump instruction , 


lg =k4+34+3-k-(G-I+CU-D)iflLSkAGSN, 
ij=4 fl < kag SN; 
=o ie Sky 


Uo =k+3+3-k-min(k,N), 
I” =I'4+4-min(k,N), 


Ww =U 44-h. 


The first idea is that each returning absolute jump can be replaced by an 
absolute jump to the beginning of the instruction sequence 


+stack.push:7 ; ##1;##1” , 


where j is the position of the returning absolute jump instruction concerned 
and | is the position of the instruction to jump to. The execution of this 
instruction sequence leads to the intended jump after the return position 
has been put on the stack. In the case of stack overflow, deadlock occurs. 
The second idea is that each return can be replaced by an absolute jump to 
the beginning of the instruction sequence 


—stack.topeq:1 ; ##1/ ; stack.pop ; ##1; 


—stack.topeq:n ; #741!” ; stack.pop ; ##n ; 
Hl” , 


where n = min(k,N). The execution of this instruction sequence leads 
to the intended jump after the position on the top of the stack has been 
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found by a linear search and has been removed from the stack. In the 
case of an empty stack, deadlock occurs. To enforce termination of the 
program after execution of its last instruction if the last instruction is a plain 
basic instruction, a positive test instruction or a negative test instruction, 
##0 ; #40 is appended to w1(u1) ;...; We(ux). Because the length of the 
translated program is greater than k, care is taken that there are no non- 
returning or returning absolute jumps to instructions with a position greater 
than k. 

Let P be a PGLD,; program. Then pgldrj2pgld(P) represents the 
meaning of P as a PGLD program. The intended behaviour of P is the 
behaviour of pgldrj2pgld(P) on interaction with a stack. That is, the 
behaviour of P, written |Pleaup,;; is |pgldrj2pg1ld(P)|perp /stack Stack init. 

According to the definition of the behaviour of PGLD,; programs given 
above, the execution of a returning jump instruction leads to deadlock in the 
case where its position cannot be pushed on the stack and the execution of 
a return instruction leads to deadlock in the case where there is no position 
to be popped from the stack. In the latter case, the return instruction is 
wrongly used. In the former case, however, the returning jump instruction 
is not wrongly used, but the finiteness of the stack comes into play. This 
shows that the definition of the behaviour of PGLD,; programs given here 
takes into account the finiteness of the execution environment of programs. 


13. Conclusions 


We have studied sequential programs that are instruction sequences with 
direct and indirect jump instructions. We have considered several kinds of 
indirect jumps, including return instructions. For each kind, we have defined 
the meaning of programs with indirect jump instructions of that kind by 
means of a translation into programs without indirect jump instructions. 
Each translation determines, together with some memory device (a register 
file or a stack), the behaviour of the programs concerned under execution. 

The increase in the length of a program as a result of translation can 
be reduced by taking into account which indirect jump instructions actu- 
ally occur in the program. The increase in the number of steps needed 
by a program as a result of translation can be reduced by replacing linear 
searching by binary searching or another more efficient kind of searching. 
One option for future work is to look for bounds on the increase in length 
and the increase in number of steps. 
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In [8], we have modelled and analysed micro-architectures with pipe- 
lined instruction processing in the setting of program algebra, basic thread 
algebra, and Maurer computers [13, 14]. In that work, which we consider 
a preparatory step in the development of a formal approach to design new 
micro-architectures, indirect jump instructions were not taken into account. 
Another option for future work is to look at the effect of indirect jump 
instructions on pipelined instruction processing. 
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